This kind of URI specifies a local object relative to the current
directory (unless you have set a <BASE HREF=..>, which is not
recommended; see below). If you want to refer to an object located in
the parent directory, you can use ``../'' as prefix.
Sometimes, when your project starts to become rather complex, you
create subdirectories for to structure the whole thing. As example, I
prefer to create a directory image/, where all images for
buttons and logos are placed.
Creating a link to an image from the project root directory is no
problem, it's URI simply is image/logo.gif. But if your
current page is somewhere deeper in your project path, eg.
people/hugo/hugo.html, you need to refer to the same
image using ../../image/logo.gif. So you always have to
know the directory level of your current page.
One solution would be to define a <BASE HREF="path to main
document">. But then, all your links have to be relative to
the directory you have specified with the HREF attribute.
This is very annoying if you need to refer to files located in the
same directory.
But, thanks to hsc, here's the solution to this problem: if you
do not define a <BASE>-URI, all relative links are processed as
usual. Only if the URI starts with a colon (``:''), it refers to a file
relative to the root directory of your project.
For example, an <IMG SRC=":image/back.gif" ALT="back"> will
always refer to the same image, regardless whether this tag is called
from a file called welcome.hsc or
people/hugo/hugo.hsc. The difference can only be
recognised in the html objects: for the first case, an <IMG
SRC="image/back.gif" ALT="back"> will be created. For the second
one, it will be <IMG SRC="../../image/back.gif"
ALT="back">.
For the html document, these URIs will be translated to relative URIs as described above.
Different to the project relative URIs described above, server relative URIs are not a feature of hsc, but of the standard URI schema. As they usually only cause problems (especially when reading documents locally with an off-line browser), you will not find any further information about them here. Although the idea behind them would not be so bad at all, you should try to avoid them within ridiculous linking model like the one of the w3, as this more or less only defines a filecopy operation across networks.
For those who really can not live without them, the CLI-option SERVERDIR adds some basic support. With this option set to a valid directory, such URIs will be converted to relative URIs internally, and most features of hsc will work with them as usual. However they will show up in the html document with their original value, with all problems remaining for other applications.
http://www.playboy.com/'' or
``ftp://wuarchive.wustl.edu/pub/aminet/''. As hsc acts only
on objects which can be found on the local disk and does not establish
any network connections, several features like like link validation or
the CLI-option GETSIZE will not work on such URIs.
For html, they point to a specific location in a document and can
be created using <A NAME=..> and are referenced liked <A
HREF="file.html#id">. Normally, hsc will only validate
references within the current document. If you refer to an ID within
another document, only the existence of the corresponding file at all
will be validated.
This changes if you start to utilize the project management capabilities. On demand, hsc can remember which IDs have been specified within a document, and will utilise these data to validate references to IDs, too.